home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 2⁄16⁄90 / 0682-TTEView Question (Co-Feb90 < prev    next >
Encoding:
Text File  |  1990-02-16  |  3.1 KB  |  77 lines  |  [TEXT/GEOL]
  1. Item    7851557                         15-Feb-90        10:13PST
  2.  
  3. From:   MADA2                           MacApp Dev Assoc, Curtis Faith,IVC
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:    TTEView Question (Compuserve)
  8.  
  9. From the Compuserve forums comes this question about some of the internals of
  10. TTEView.  I have not personally spent enough time inside TTEViews to be able to
  11. answer this question intelligently.
  12.  
  13. Anyone have any comments?
  14.  
  15. ____________________
  16. From: John MacVeigh 72467,2141
  17.  
  18. While trying to debug a problem with a TTEView object I have run into what I
  19. think is a flaw with the use of the fSavedTEHandle field and the fFreeText
  20. field. The flaw only surfaces when TTEView.StuffText is called more than once.
  21. Here is my thinking:
  22.  
  23. The purpose of fSavedTEHandle appears to be to provide a valid handle for the
  24. fHTE^^.hText field when fHTE is passed to TEDispose (see TTEView.Free).
  25. Apparently the idea is to hold on to the handle which is originally assigned to
  26. hText by the TENew call. This handle is placed back into the fHTE record just
  27. before TEDispose is called. This allows the fText field to be freed separately.
  28.  
  29. So far, so good. Now let's look at fFreeText. This Boolean controls whether the
  30. fText field is actually disposed when TTEView.Free is called. An alternate name
  31. for this field could be fTEOwnsText. That is, if the TTEView object owns the
  32. text, then it may dispose of it at will. Otherwise someone else is responsible
  33. for it, indeed, may care very much about it.
  34.  
  35. Now, finally, look at TTEView.StuffText. If the text to be stuffed (theText) is
  36. different each time that StuffText is called, the routine will end up throwing
  37. away fSavedTEHandle and saving the old hText field before stuffing the new
  38. text.
  39.  
  40. The result is that, during multiple calls to StuffText, fSavedTEHandle becomes
  41. a cache of previous text handles, rather than a holder for the original hText
  42. field. It does not check the setting of fFreeText, and thus can violate the
  43. rule that someone else is responsible for freeing the fText field.
  44.  
  45.  IF fSavedTEHandle <> theText THEN
  46.    BEGIN
  47.    DisposIfHandle(fSavedTEHandle);  { ...we have no choice but to dispose it }
  48.    fSavedTEHandle := fHTE^^.hText;  { Save existing handle }
  49.    END;
  50.  
  51. (I do not agree with the comment about no choice) should be replaced with:
  52.  
  53.  If fFreeText & (theText <> fHTE^^.hText) Then
  54.    DisposIfHandle (fHTE^^.hText);
  55.  
  56. Essentially this says that if we are stuffing a new handle, just forget about
  57. the previous one (though if we own it [fFreeText = True] then we kill it off,
  58. as well). The rest of the routine remains unchanged.
  59.  
  60. In addition, TTEView.Free needs to check that fText and fSavedTEHandle are not
  61. the same handle, so that the hText field is not disposed twice. Umm, I'll leave
  62. this as an exercise for the reader.
  63.  
  64. I think these changes enforce the setting of fFreeText without failing when
  65. someone tries to be (overly) clever and repeatedly stuffs fHTE^^.hText back
  66. into the TTEView.
  67.  
  68. Have I missed anything here?
  69.  
  70. --John MacVeigh
  71. _________________
  72. Send replies to me at MADA2 and I will forward them to John.
  73.  
  74. - Curtis
  75.  
  76.  
  77.